✨ expose Result<T> as public API#1149
Conversation
rauhryan
force-pushed
the
rr/all-settled-898
branch
from
8a87a15 to
e186787
Compare
cowboyd
left a comment
cowboyd
left a comment
There was a problem hiding this comment.
I know I said that we should be perfectly aligned with the JavaScript, but now I'm having second thoughts. The reason is because "fulfilled" and "rejected" are very explicitly Promise nomenclature, and operations are not promises.
Also, we have a Result interface which we use everywhere.
thoughts?
If the goal is to reduce friction for newcomers, aligning with familiar JavaScript terminology like "fulfilled" and "rejected" makes sense. Even though operations aren’t Promises, these terms are widely understood and lower the learning curve. The alternative would require introducing additional abstractions—such as Effection’s box utility or similar constructs from other libraries to achieve the same behavior. |
rauhryan
force-pushed
the
rr/all-settled-898
branch
from
5915edd to
156db90
Compare
rauhryan
changed the title
|
Split this into stacked PRs as requested. This PR is now the base PR for exposing |
commit: |
rauhryan
force-pushed
the
rr/all-settled-898
branch
from
cf8dd4c to
d1f564c
Compare
rauhryan
force-pushed
the
rr/all-settled-898
branch
from
d1f564c to
98c30ba
Compare
4 participants
Motivation
Result<T>,Ok(), andErr()are already exported from the public module surface, but they are still marked@ignorein the API docs.This PR makes those APIs explicitly public so follow-on work can reference
Result<T>without relying on undocumented types.Approach
@ignorefromResult<T>,Ok(), andErr()unbox()internalThis is the base PR for the stacked
allSettled()work.